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REMARKS/ARGUMENTS 

Reconsideration of this application is respectfully requested. 

The rejection of claims 1, 4, 5 and 6 under 35 U.S.C. §102 as allegedly anticipated by 
Yohe '943 is respectfully traversed. 

In a nutshell, applicant's claims deny client access to a server file if the digital signature 
associated with that file is invalid while Yohe '943 permits client access to a server file if a hash 
function comparison (apparently what the Examiner is considering to be a digital signature) fails. 
Yohe '943 is merely directed towards increasing the speed of cache data supply systems while 
maintaining the most current version of a master file data in each cache location. Hash functions 
are used to provide a quick technique to check for identical file content. Cryptographic digital 
signatures are not even utilized. 

To the extent that Yohe has any relevance whatsoever, it actually teaches something that 
would be contrary to the applicant's claimed arrangements where a requested file is not provided 
if digital signature comparison processes fail. 

Yohe has a different aim from applicant's invention. The object of Yohe is to increase 
the speed with which a remote client computer 12 can access data and directories normally 
stored on a file server computer 18 (see column 2, lines 24 and 25). Yohe is especially useful if 
the connection speed from the remote client computer 12 and a file server computer 18 is low 
(see column 2, lines 9 to 18). 



-9- 



952877 



WRIGHT efal 
Appl.No. 09/936,210 
May 9, 2005 

Yohe increases the speed with which the user of the remote client computer 12 is able to 
access a file by the well-known device of caching (i.e., storing) a copy of recently accessed files 
in the remote client's memory (30 to 34). When the user of the remote client computer 12 later 
asks for the same file then it can be provided from the remote client computer's memory (30 to 
34) rather than having to be downloaded from the file server computer 18 over the slow modem 
link (column 2, lines 9 to 16 again). 

A problem with caching is that there is no guarantee that the file stored in the user's 
computer's memory is up-to-date. Yohe checks the file is up-to-date by having the cache 
verifying computer 14 calculate what Yohe calls a "signature" of the file. In fact, as will be 
explained below, what is calculated I not a digital signature as that term is normally used in the 
art, but a "hash value" or "message digest". A hash value or message digest is typically much 
shorter than the file from which the hash value is generated - in addition, the value is very 
sensitive to any change in the file from which it is generated. These points are explained in the 
attached pages copied from the book "Applied Cryptography" referenced at lines 4-6 on page of 
the applicant's specification. 

Thus, if the user of the remote client computer 12 requests a file that is in the remote 
client computer's memory (30 or 35). Yohe has the remote client 12 calculate a first hash value 
from the file in the cache (see column 6, lines 22 and 23). The calculated value is sent to the 
Cache Verifying Computer 14 as part of a VERIFY request (column 6, lines 23 to 26). The 
Cache Verifying Computer 14 then calculates a second hash value from the version of the file 
stored at the file server computer 18 (column 6, lines 27 to 29). 
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The Examiner will realize that if the file cached at the remote client computer 12 is up-to- 
date then it will be the same as the file provided by the file server computer 18 and used by the 
Cache Verifying Computer 14 to calculate the second hash value. Since the two files are the 
same, then it follows that the first and second hash values will be the same. 

Common sense tells us that if the two files are the same, then there is no need to update 
the cache on the remote client computer 12. All that is needed is for the Cache Verifying 
Computer 14 to send a message that the copy of the file at the remote client computer 12 is up- 
to-date. Unsurprisingly, this is what Yohe does, column 6, lines 35 to 37. In that case, the cache 
provides the usual performance enhancement in that the user of the remote client computer 12 
des not need to wait for the file to be transmitted over the slow modem link 22, instead the only 
delay is for the transmission of the shorter message indicating that the cached copy of the file is 
up-to-date. 

The above explanation shows how Yohe achieves the benefits of caching without risking 
presenting the user of the remote client computer 12 with an out-of-date copy of the requested 
file. 

A consideration of the operation of Yohe and the applicant's claimed arrangements 
reveals a crucial distinction. In Yohe, if the file has been altered, then the file is transmitted by 
applicant's server computer 18. That is the complete opposite of the invention claimed in claims 
1, 4, 5 and 6 where, if the file has been altered, then it is not transmitted by the sever computer. 

Also, as mentioned above, Yohe does not use "digital signatures" as that term is normally 
understood by those in the art. The fact that what Yohe provides are in fact hash values can be 
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seen from the references to specific algorithms later on in the Yohe patent (specifically at 
column 11, line 63 and column 13, line 39). The two RFC's referred to are available via 
http://www.ietf.org/rfc.html - note that the second reference should be to RFC 1321 not RFC 
1322. 

The rejection of claim 2 under 35 U.S.C. §103 as allegedly being made "obvious" based 
on Yohe '943 in view of Atkinson '012 is also respectfully traversed. 

Fundamental distinctions over the primary Yohe reference with respect to parent claim 1 
have already been noted above. 

Atkinson '012 seems to correspond closely to the Authenticode ® software described in 
the last paragraph of page 5 of the applicant's specification. As pointed out in the first paragraph 
on page 6 of the specification, the mere fact that the executable file is provided to the client 
computer is enough to present a security problem which the present invention overcomes by 
denying the client computer access to the file on the server computer. 

Neither Yohe nor Atkinson suggest that an invalid signature should prevent the 
transmission of data from a server computer to a client computer. As explained above, if 
anything, Yohe teaches the opposite. Since neither reference teaches the last feature of claim 1, 
the combination of the two would not render claim 1 obvious, let alone claim 2. 

The rejection of claim 3 under 35 U.S.C. §103 as allegedly being made "obvious" based 
on Yohe '943 in view of Farber '791 is also respectfully traversed. 
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Once again, fundamental deficiencies of the primary Yohe reference have already been 
noted above with respect to parent claim 1. 

Farber '791 teaches that a file may "expire" at a date and time stored in relation to that 
file - the file will then be deleted. The Examiner claims that modifying Yohe by introducing this 
idea from Farber would lead to the invention claimed in claim 3. It would not - the Examiner 
has not shown that Farber or Yohe teaches the last feature of claim 1. 

Accordingly, this entire application is now believed to be in allowable condition and a 
formal Notice to that effect is respectfully solicited. 

Respectfully submitted, 
NIXON & VANDERHYE P.C. 



LSN:vc 

1100 North Glebe Road, 8th Floor 
Arlington, VA 22201-4714 
Telephone: (703) 816-4000 
Facsimile: (703) 816-4100 




By: 

lo. 25,640 
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CHAtrt^l Protocol Building Blocks 




ds^r^hVur^her^ For pubhckcy cryptography, w. need something 

S Sections "yP'"«"Ph>c applicauons for one-way functions-see 

A trapdoor one-way hmction is a special type of one-way function one with a 
other Jirecnon. But. if you know the secret, you can easily compute the function in 

Taking a watch apart is a good example of a trap-door one-way function It is easy 
o isassemble a watch into hundreds of minuscule pieces. It is very dXuh to p« 
those t.ny pieces back together into a working watch. However with the ecre 



2 A Om-Wm Mash IRjnctdons 

A onfr-way haoh hmction has many namea: compression function, contraction hinc- 
t^n message digest. fingen.rint, cryptographic checksum, message integrity check 
(MJC), and manipulation detection code (MDC). Whatever you call it, it ircentral to 
^^Zr'''"^'''''' '"""^^"^ another'building blo^k fo? many 

Hash functions have been used in computer science for a long time. A hash func- 

trin^lc'.! td"'"" -"""r'"'/'"^ °' '^''^ ' ^Sriable-length input 

;5 ? , .3 rTT' r " '° " 'ength (generally smalkr) output 
otnng (called a hash value). A simple hash function would be a function that takes 
pre-image and returns a byte consisting of the XOR of all the input bytes 
wh«K.r" rV* ""gc^Print the pre-image; to produce a value that indicates 

K ul'''*^" ^'•^''y " ^^'^ """^ " 'he real pre "mage 

Because hash functions are typically many-to-one. we cannot use them to detS' 
mine with certainty that the two strings are equal, but we can use themTo get a ^a 
sonable assurance of accuracy. ^ 

hash function is a hash function that works in one direction It is easy 
to compute a hash value from pre-.magc. but it is hard to generate . pre-^mL" thit 

w/y Given ToaS^Jrt'' ""^^ "^^"^ """"'^ ™cntio„'ed iHo't ! 

?Ah P'-rt.cular byte value. ,t is trivial to generate a string of bytes whose 

S f value You can t do that with a one-way hash functio^A good one-way 
same hsTv'u'r'" colHsion-fre. It .s hard to generate two pre-imjges ^ithZ 

onrL^^'hltT"'"" "° *° P'^"" The security of a 

.„ !„ / u.""'"" " one- wayness, Tlie output is not dependent on the input 
haK^Su m S '>*;,^»'*"«Vn 'he pre-image changes, on the average 

Mef Ji A * '» computationally unfeasi 

ble to find a pre-image that hashes to that value "nxcasi 
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Think ul It •'1 ^^ly ^ii\c;erpnniing filca. It you want to verify thai someone has 
J pjriiLiilJr UW (ih.it you .ilso hjvc). hut you don't want him to ycnd it to you, then 
isb him foi thf hash v.iUie If he sends you the correct h;ish vnhie, then it is ;Umost 
ct'fCJin th-ii l^t' Nas ih.tt hlc This is particularly useful in financial transactions, 
vtfhcrrc you AoWi vv.uu .i vviihdrawal of $100 to turn into a withdrawal of $1000 
sonKwhcre in (he network Normally, you would use a one-way ha5»h function 
without a key. so that anyone e;^n verify the hash. If you want only the recipient to 
b« dbk- to verify the ha^h, then read the next section. 

H^aasage Authentication Codes 

A mcsHjge auihrntication code (MAC), also known as a data authentication code 
p iDAC). is a (»ne w;iy hash funcnon with the addition of a secret key (see Section 
ig.MI The hash v;iluc is a function of hnth the pre image and the key. The theory 
19 exactly the same as lush functionfi, except only someone with the key ean verify 
the hash vaUie You can create a MAC out of a hash function or a block encryption 
algorithm, there are also dedicated MACs. 

2.5 CoMMvmcMnom Usmc Pubuc-Key Cryptokgkapihiy 

Think of a symmetric aljjorithm as a safe. The key it* the combination. Someone 
with the cnmhinatiiin can open the safe, put a document inside, and close it again. 
Someone else with the combination can open the safe and take the document out. 
Anyone without the combination im forced to learn safecracking. 

In m6, Whufield Diffie and Martin Hcllman changed that paradigm of crypcoK 
rjphy forever |496| (The NSA ha.s claimed knowledge of the concept as early as 
J966. but has nfft red no proof.) They de.scrihed public-key cryptography. They used 
two different keys— one public and the other private. It is computationally hard to 
lieduce the rn vato key from the public key. Anyone with the public key can encrypt 
a message hut nor decrypt it. Only ihe person with the private key can decrypt the 
mes8»igc It is as If someone turned ihe cryptographic safe into a mailbox. PuttinK 
mail in the mjilhox is analogous to encrypting with the public key; anyone can do 
It Just opcrn the s ot and drop n in. Getting mail out of a mailbox is analogous to 
aceryptmg w.th the private key. Generally it's hard; you need welding torches 
However, .f you have the secret (the physical key to the mailbox), it's easy to get 
"liiiJ out of a mailbox / ^ t*^*^ 

Mathematically, the process is based on the trap-door one-way functions previ- 
nSl r""'^ Encryption is the easy direction. Instructions for encryption are the 
Ld^h 'l' '"^'7^' '" ^^^^^yP^ message Decryption is the hard direction. It's 
7y^l rt 'iT""^ I " '''."P^' ""''^ ^''^ computers and thousands (even millions) 
chJnnva. / \lr'uT "^^ or trapdoor, is 

Th ' T ^''^ ^^^^^VPtion ..s as easy as encryption. 

IS how Alice can send a message to Bob using public-key cryptography: 

111 Alice and Bob a«ree on a public-key cryptosy^item. 



